Single Sign-On |
|
Process Platform uses SOAP wrapped XML messages for all platform communication. For instance, retrieving a list of customers from an SAP system requires a number of SOAP messages that flow between the required systems and components. In the traditional security mechanism, the Process Platform Web Gateway authenticates the sender of a SOAP message, after which the SOAP message is routed to a service container. The service container then checks the Access Control List to decided to perform the requested service, or deny service access. Although unlikely, this approach theoretically poses a security vulnerability if someone would (a) be able to evade identify verification by the Web gateway; and (b) is able to manipulate the Access Control List (ACL).
To minimize security risks, the new SSO implementation based on the SAML standard works fundamentally different. SOAP message senders are no longer required to validate identify through the Web Gateway. Instead, senders have to request SAML credentials from the new Process Platform SSO component in form of so called tokens. These tokens are attached to every sent SOAP message, and the receiving service container uses the SSO component to validate the identity based on these tokens. service container then use the ACL mechanism to determine if a user is allowed to access the requested service. The SAML tokens are reusable in that they can be used for other service requests as well, potentially directed at a different service container.
Process Platform provides the Single Sign-On (SSO) feature to handle the process of authentication and authorization of users in a reliable and secure manner. SSO is based on the Security Assertion Markup Language (SAML) and the Web Service Security (WS-Security) standards.
Single Sign-On provides a trusted identity to users of Process Platform. This trusted identity is given in the form of signed SAML assertions. A client can get these SAML assertions by correctly authenticating with Single Sign-On. SAML assertions are the proof that a user is correctly authenticated with Single Sign-On. The following diagram describes this process.
Figure
The client then includes these assertions in the request header of a SOAP request to the service container. The service container reads the assertions and checks if the user is authorized to complete the request. After correct authorization, the request is executed. The following diagram describes the request to the service container.
Figure
The SAML assertions can be provided by Process Platform Single Sign-On or by any other source that supports the SAML standard. The credentials supplied to Single Sign-On can consist of all the identity types that Process Platform supports.
If the SAML assertions are signed, the service container must trust the Single Sign-On which provided the assertions. Trust relations can be set in the Trust Stores tab of Security Administration task.